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DETAILED ACTION 

Claim Objections 

Claim 42 is objected to because of the following informalities: the limitation "means for 
determining the service class of the payload data from said IP data packets associated with said 
PDP context" is repeated in lines 12-13. Appropriate correction is required. 

Claim Rejections - 35 USC § 112 

1 . The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

2. Claims 31, 36, 39, 40 and 42 are rejected under 35 U.S.C. 1 12, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

3. Claim 3 1 recites the limitation "said IP data packets" in line 2. There is insufficient 
antecedent basis for this limitation in the claim. 

4. Claim 36 recites the limitation "the payload data" in line 10. There is insufficient 
antecedent basis for this limitation in the claim. 

5. Claim 39 recites the limitation "said means for communicating" in lines 2-3. There is 
insufficient antecedent basis for this limitation in the claim. Specifically, it is not clear if the 
means for communicating is the same as the means for sending in claim 37, or a different means 
for communicating. For the purpose of examination it is assumed that the means for 
communicating and means for sending are the same. 
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6. Claim 40 recites the limitation "said accumulated volume" in lines 1-2. There is 
insufficient antecedent basis for this limitation in the claim. 

7. Claim 42 recites the limitation "said service class for the upstream payload" in lines 16- 
17. There is insufficient antecedent basis for this limitation in the claim. 

8. Claim 42 recites the limitation "said service class for the downstream payload" in lines 
18-19. There is insufficient antecedent basis for this limitation in the claim. 

9. Claim 42 recites the limitation "said extension headers" in line 20. There is insufficient 
antecedent basis for this limitation in the claim. Specifically it is unclear whether the extension 
headers with downstream information or extension headers with upstream information is being 
referred to. For the purpose of examination, it is assume to refer to the extension headers 
containing downstream information. 



Claim Rejections - 35 USC § 101 

10. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

1 1 . Claims 27-34 are rejected under 35 U.S.C. 101 because the claimed invention is directed 
to non- statutory subject matter. Specifically, these claims refer to a packet data unit which is a 
data structure and is not statutory subject matter. 

Claim Rejections - 35 USC §102 

12. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 
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(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

13. Claims 22-24, 26-28, 31, and 33-35 are rejected under 35 U.S.C. 102(e) as being 
anticipated by US2004/0266394 to Mizell et al. 

Regarding claim 22, Mizell teaches a method of communicating charging information for 
a particular mobile station in a network including at least a serving node and a gateway node, 
comprising the following steps: 

receiving, at said gateway node, a data packet comprising a header and a payload (i.e. 
Mizell teaches a GGSN (gateway GPRS service node) downloading a data packet from an IP 
network; paragraph 0030. IP packets are known to comprise headers and payloads); 

identifying a particular Packet Data Protocol (PDP) context for a particular mobile station 
(i.e. the GGSN downloads the packet upon request by a MN (mobile node) for which a PDP 
context has been created and delivers the packet to the MN via a SGSN (serving GPRS support 
node), therefore identifying a particular PDP context; paragraph 0030, 0032); 

gathering, at said gateway node and from said received data packet, charging information 
relating to said PDP context (i.e. the GGSN extracts charging info; paragraph 0014); 

creating a GPRS Tunneling Protocol (GTP) packet data unit, said GTP packet data unit 
including a header, a payload, and a pre-determined service class extension header (i.e. GGSN 
creates a GTP packet by encapsulating the downloaded data packet; paragraphs 0014, 0030. The 
GGSN uses a GTP extension header to communicate charging information to the SGSN; 
paragraph 0013); and 
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transmitting, from said gateway node to said serving node, said GTP packet data unit 
containing said charging information (i.e. GGSN forwards the GTP packet tot the SGSN; 
paragraph 0014); 

wherein said charging information relates to said PDP context for said mobile station (i.e. 
the charging information relates to the packet requested by the MN under the PDP context; 
paragraph 0014), said pre-determined service class extension header is reserved for service class 
information pertaining to at least one IP packet payload for said PDP context (i.e. the extension 
header is used to provide charging information pertaining to the data packet, therefore reserved; 
paragraph 0014) and said header comprises a next extension header type indicating that said pre- 
determined service class extension header follows (i.e. the next extension header flag is used; 
paragraph 0036). 

Regarding claim 23, Mizell teaches the method according to claim 22, wherein said 
network includes a charging node associated with said serving node, the method further 
comprising the following steps after said transmitting step: 

receiving, at said serving node, said charging information (i.e. the SGSN receives the 
GTP packet from the GGSN; paragraph 0032); and 

sending, from said serving node to said charging node, information corresponding to said 
charging information (i.e. the SGSN sends a charging record to the CGF (charging gateway 
function); paragraph 0035). 

Regarding claim 24, Mizell teaches the method according to claim 22, wherein said 
gathering step further comprises the following steps: 



Application/Control Number: 10/596,014 Page 6 

Art Unit: 2617 

performing a packet inspection of said received data packet (i.e. the GGSN inspects the 
packet for content, source, and destination; paragraph 0030); and 

assigning a predefined service class for said data packet based on said packet inspection 
(i.e. the GGSN uses an extension header to pass accounting information to the SGSN consisting 
of content information, therefore assigning a service class; paragraph 0030). 

Regarding claim 26, Mizell teaches the method according to claim 22, wherein said 
network comprises a GPRS network, said serving node comprises a Serving GPRS Support 
Node, and said gateway node comprises a Gateway GPRS Support Node (i.e. Mizell teaches a 
GPRS network with GGSN and SGSN nodes; paragraph 0025). 

Regarding claim 27, Mizell teaches a packet data unit used for communicating charging 
information, said packet data unit comprising: 

a header; a payload (i.e. a GGSN sends a GTP packet to a SGSN comprising a header and 
payload; paragraphs 0014, 0030); and 

at least one predetermined service class extension header (i.e. the GGSN uses a GTP 
extension header to communicate the charging rate information; paragraphs 0014, 0030, 0033); 
and 

wherein said header comprises a next extension header type indicating that a 
predetermined service class extension header follows (i.e. the GGSN set a flag to indicate the use 
of an extension header; paragraph 0033), 

said predetermined service class extension header being reserved for service class 
information pertaining to at least one IP data packet payload for a given PDP context (i.e. the 
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extension header is used to provide charging information pertaining to the data packet, therefore 
reserved; paragraph 0014). 

Regarding claim 28, Mizell teaches the packet data unit according to claim 27, wherein 
said pre-determined service class information is associated with a service class of said payload of 
said packet data unit (i.e. the charging rate is based on the packet content, therefore associated 
with a service class of the payload; paragraphs 0013, 0014). 

Regarding claim 31, Mizell teaches the packet data unit according to claim 27, wherein 
said payload data of said IP data packets relates to both payload data transmitted upstream and 
payload data transmitted downstream for said PDP context and for a given user (i.e. Mizell 
teaches encapsulating into GTP packets IP packets downloaded (downstream) at the request 
(upstream) of an MN through a PDP context, therefore the GTP packet is related to both the 
request and the downloaded IP packet; paragraph 0030, 0032). 

Regarding claim 33, Mizell teaches the packet data unit according to claim 27, wherein 
said packet data unit is a GTP-U PDU packet and said payload is a GTP-U PDU payload (i.e. the 
GTP packet is transferred from GGSN to SGSN, therefore a GTU-U packet; paragraph 0014). 

Regarding claim 34, Mizell teaches the packet data unit according to claim 27, wherein 
said extension header comprises at least a main service class field and a sub-class field (i.e. 
extension header comprises extension header content (main field) and next extension header type 
(sub-field); paragraph 0036). 

Regarding claim 35, Mizell teaches a gateway node for communicating within a system 
performing packet inspection and service classification, said system including a packet data 
network and a serving node, wherein IP data packets may be communicated for identification of 
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a given predetermined service class out of a plurality of predetermined service classes within 
said system, said gateway node comprising: 

means for receiving, at said gateway node, an IP data packet from said packet data 
network (i.e. GGSN receives a data packet from an IP network, therefore a receiver on a network 
port; paragraph 0025, 0030, 0039); 

means for extracting the payload of said IP data packet (i.e. GSGN inspects the payload 
of a downloaded IP packet, therefore a processor for extracting a payload; paragraph 0030, 
0040); 

means for determining a value, out of a plurality of values corresponding to a plurality of 
different service classes, said determined value corresponding to a service class for said payload 
(i.e. GGSN assigns a charging rate for each downloaded packet based on the packet contents 
(service class), therefore a processor for determining packet content type; paragraph 0030, 0041); 

means for assigning said determined service class to a service class extension header (i.e. 
GGSN assigns a charging rate for each downloaded packet based on the packet contents, 
therefore a processor; paragraph 0030, 0040); 

means for creating a packet data packet unit by including said service class extension 
header; means for inserting said payload in said packet data packet unit; (i.e. GGSN creates a 
GTP packet by encapsulating the downloaded packet, therefore a processor for creating packets; 
paragraph 0030, 0040); and 

means for transmitting said packet data unit from said gateway node to said serving node 
(i.e. GGSN transfers the GTP packet to a SGSN, therefore a transmitter on a Gn interface; 
paragraph 0030, 0039). 
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Claim Rejections - 35 USC § 103 

14. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

15. Claim 25 is rejected under 35 U.S.C. 103(a) as being unpatentable over Mizell in view of 
US 2002/0058496 to Bos et al. 

Regarding claim 25, Mizell teaches the method according to claim 23, but does not 
specifically teach wherein said charging node comprises a CAMEL SCP node and said charging 
information is signaled by means of the CAP protocol. However, at the time the invention was 
made the preceding limitation was known in the art of communications. 

Bos teaches a GPRS network comprising CAMEL nodes that uses a CAP protocol 
interface to communicate charging information between the bearer level system (i.e. the GGSN 
and the SGSN) and a CAMEL SCP (service control point) in order to remove the need for a 
separate charging interface and thus optimize the network architecture. Therefore it would have 
been obvious to one of ordinary skill in the art at the time of invention to modify the charging 
function of Mizell to incorporate a CAMEL architecture as taught by Bos in order to optimize 
the network architecture. 

16. Claims 29-30, 32, 36-38, and 41 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Mizell in view of US 2008/0096523 to Lundin et al. 

Regarding claim 29, Mizell teaches the packet data unit according to claim 27, but does 
not specifically teach wherein said at least one pre-determined service class extension header 
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comprises a volume count pertaining to an amount of payload of said packet data unit, said 
volume count belonging to said PDP context. However, at the time the invention was made the 
preceding limitation was known in the art of communications. 

Lundin teaches a GPRS network wherein the GGSN adds traffic type indicators to the 
GTP header that are used to indicate the appropriate charging scheme to each packet; paragraph 
0028. Lundin teaches that one of the indicators may be the chain ID (volume count) to keep 
track of the number of packets received such that those packets that cannot be identified until a 
required number of packets have been received can be processed; paragraph 0028. Therefore it 
would have been obvious to one of ordinary skill in the art at the time of invention to modify the 
GTP packets of Mizell to include chain ID as taught Lundin in order to handle packet chains. 

Regarding claim 30, Mizell teaches the packet data unit according to claim 27, wherein 
said pre-determined service class information corresponds to the service class of payload data of 
IP data packets contained in a plurality of different packet data units that are associated with said 
PDP context (i.e. the charging rate is based on the packet content, therefore associated with a 
service class of the payload; paragraphs 0013, 0014). 

Mizell does not specifically teach wherein said at least one predetermined service class 
extension header comprises a volume count corresponding to the aggregated volume of said 
payload data of said IP data packets. However, at the time the invention was made the preceding 
limitation was known in the art of communications. 

Lundin teaches a GPRS network wherein the GGSN adds traffic type indicators to the 
GTP header that are used to indicate the appropriate charging scheme to each packet; paragraph 
0028. Lundin teaches that one of the indicators may be the chain ID (volume count) to keep 
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track of the number of packets received such that those packets that cannot be identified until a 
required number of packets (aggregate volume) have been received can be processed; paragraph 
0028. Therefore it would have been obvious to one of ordinary skill in the art at the time of 
invention to modify the GTP packets of Mizell to include chain ID as taught Lundin in order to 
handle packet chains. 

Regarding claim 32, the combination of Mizell and Lundin teaches the packet data unit 
according to claim 30, wherein at least two service class extension headers are included in said 
packet data unit, said at least two service class extension headers are associated with at least two 
different service classes (i.e. Lundin teaches appending traffic type information to the header of a 
GTP packet including service class, cost info, and/or chain ID; paragraph 0028, 0044. Therefore 
it would be obvious to one skilled in the art that the combination of Mizell and Lundin teaches 
adding more than one extension headers of different types). 

Regarding claim 36, Mizell teaches a serving node for communicating with a charging 
node, said serving node comprising: 

means for receiving a packet data unit comprising a service class extension header (i.e. 
SGSN receives a GTP packet with an extension header from a GGSN, therefore a receiver on a 
Gn interface; paragraph 0033, 0039); 

means for determining a service class value from said service class extension header (i.e. 
SGSN extracts the charging information from the GTP extension header, therefore a processor 
for analyzing GTP packets; paragraph 0033, 0041); 
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means for determining a volume count, for a given service class and a given PDP context 
(i.e. SGSN has a processor to extract packet volume from the GTP packet; paragraph 0033, 
0041); 

means for storing said volume count (i.e. SGSN keeps track of the volume of packets 
delivered, therefore a processor and memory for storing volume; paragraph 0039, 0045); 

means for transmitting the payload data associated with said PDP context (i.e. SGSN 
forward the packet to the MN via a BSC or RNC, therefore a transmitter on a Gb or Iu interface; 
paragraph 0025, 0033, 0039); and 

means for sending associated values of said determined service class value and said 
volume count from said serving node to said charging node (i.e. SSGN sends a CDR containing 
volume count and charging info (service class value) to the CGF, therefore a transmitter for 
communicating with a charging node; paragraph 0035, 0039). 

Mizell does not specifically teach that the volume count is determined from the extension 
header, however, at the time the invention was made the preceding limitation was known in the 
art of communications. 

Lundin teaches a GPRS network wherein the GGSN adds traffic type indicators to the 
GTP header that are used to indicate the appropriate charging scheme to each packet; paragraph 
0028. Lundin teaches that one of the indicators may be the chain ID (volume count) to keep 
track of the number of packets received such that those packets that cannot be identified until a 
required number of packets have been received can be processed; paragraph 0028. Thus it would 
be obvious to one skilled in the art that the combination of Mizell and Lundin teaches extracting 
a volume count from a GTP extension header. Therefore it would have been obvious to one of 
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ordinary skill in the art at the time of invention to modify the GTP packets of Mizell to include 
chain ID as taught Lundin in order to handle packet chains. 

Regarding claim 37, Mizell teaches a serving node for communicating with a charging 
node, said serving node comprising: 

means for receiving a packet data unit comprising a service class extension header (i.e. 
SGSN receives a GTP packet with an extension header from a GGSN, therefore a receiver on a 
Gn interface; paragraph 0033, 0039); 

means for extracting a service class value from said service class extension header and a 
volume count (i.e. SGSN has a processor to extract packet volume from the GTP packet; 
paragraph 0033, 0041); 

means for storing said volume count, said volume count relating to a given service class 
and a given PDP context (i.e. SGSN keeps track of the volume of packets delivered to a MN 
through a PDP context and each packet's charging rate (service class), therefore a processor and 
memory for storing volume; paragraph 0039, 0045); 

means for transmitting payload data associated with said PDP context (i.e. SGSN forward 
the packet to the MN via a BSC or RNC, therefore a transmitter on a Gb or Iu interface; 
paragraph 0025, 0033, 0039); and 

means for sending associated values of said service class and said volume count from 
said serving node to said charging node (i.e. SSGN sends a CDR containing volume count and 
charging info (service class value) to the CGF, therefore a transmitter for communicating with a 
charging node; paragraph 0035, 0039). 
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Mizell does not specifically teach that the volume count is determined from the extension 
header, however, at the time the invention was made the preceding limitation was known in the 
art of communications. 

Lundin teaches a GPRS network wherein the GGSN adds traffic type indicators to the 
GTP header that are used to indicate the appropriate charging scheme to each packet; paragraph 
0028. Lundin teaches that one of the indicators may be the chain ID (volume count) to keep 
track of the number of packets received such that those packets that cannot be identified until a 
required number of packets have been received can be processed; paragraph 0028. Thus it would 
be obvious to one skilled in the art that the combination of Mizell and Lundin teaches extracting 
a volume count from a GTP extension header. Therefore it would have been obvious to one of 
ordinary skill in the art at the time of invention to modify the GTP packets of Mizell to include 
chain ID as taught Lundin in order to handle packet chains. 

Regarding claim 38, the combination of Mizell and Lundin teaches the serving node 
according to claim 37, wherein said volume count is associated with an accumulated volume 
count pertaining to a given PDP context (i.e. Lundin teaches keeping track of packet chains, 
therefore accumulated volume count; paragraph 0028). 

Regarding claim 41, Mizell teaches a gateway node for communicating within a system 
performing packet inspection and service classification, said system comprising a packet data 
network and a serving node, wherein IP data packets comprising payload data may be 
communicated for identification of a given predetermined service class out of a plurality of 
predetermined service classes within said system, said gateway node comprising: 



Application/Control Number: 10/596,014 Page 15 

Art Unit: 2617 

means for receiving, from a packet data network, an IP data packet in a continuous 
downstream of IP data packets associated with a given PDP context (i.e. GGSN receives a data 
packet from an IP network on request from a MN through a PDP context, therefore a receiver on 
a network port; paragraph 0025, 0030, 0039); 

means for receiving a service class identification for said IP data packet; 

means for identifying a service class for the payload data of said IP data packet, said 
payload data being associated with said PDP context (i.e. GGSN assigns a charging rate for each 
downloaded packet based on the packet contents, therefore a processor for identifying a service 
class; paragraph 0030, 0041); 

means for assigning said identified service class to a service class extension header (i.e. 
the GGSN uses a GTP extension header to communicate charging information based on packet 
content (service class), therefore a processor for assigning identified service classes to extension 
headers; paragraph 0030, 0033, 0040); 

means for inserting said service class extension header and said payload data in a packet 
data unit; (i.e. GGSN creates a GTP packet by encapsulating the downloaded packet and adding 
an extension header, therefore a processor for creating packets; paragraph 0030, 0040); and 

means for transmitting said packet data unit to said serving node (i.e. GGSN transfers the 
GTP packet to a SGSN, therefore a transmitter on a Gn interface; paragraph 0030, 0039). 

Mizell does not specifically teach: means for determining whether said IP data packet is 
incompletely classified; means for storing an aggregated volume count associated with 
incompletely classified payload data associated with said PDP context; means for storing 
information associated with incompletely classified IP data packets for said PDP context; means 
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for storing an aggregated volume count for incompletely classified payload data associated with 
said PDP context; and means for assigning an aggregated volume count for previously 
incompletely classified payload data of said PDP context to said service class extension header; 
however, at the time the invention was made the preceding limitation was known in the art of 
communications . 

Lundin teaches a GPRS network wherein the GGSN adds traffic type indicators to the 
GTP header that are used to indicate the appropriate charging scheme to each packet; paragraph 
0028. Lundin teaches that one of the indicators may be the chain ID (volume count) to keep 
track of the number of packets received of a packet chain so that such chains can be properly 
processed; paragraph 0028. Packet chains are packets for which a service class in unable to be 
determined until a required number of packets have been received, therefore incompletely 
classified payloads; paragraph 0028. Thus it would be obvious to one skilled in the art that the 
combination of Mizell and Lundin teaches a processor for determining if a packet is part of a 
chain packet (identifying incompletely classified data) and storing an chain ID value (aggregated 
volume count or information associated with incompletely classified payload data). Therefore it 
would have been obvious to one of ordinary skill in the art at the time of invention to modify the 
GTP packets of Mizell to include chain ID as taught Lundin in order to handle packet chains. 
17. Claims 39-40 are rejected under 35 U.S.C. 103(a) as being unpatentable over Mizell and 
Lundin as applied to claim 37 above, and further in view of Bos. 

Regarding claim 39, the combination of Mizell and Lundin teaches the serving node 
according to claim 37, but does not specifically teach wherein said charging node is a CAMEL 
node and the procedures used by at least one of said means for communicating with said 
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CAMEL node is following CAMEL reporting procedures. However, at the time the invention 
was made the preceding limitation was known in the art of communications. 

Bos teaches a GPRS network comprising CAMEL nodes that uses a CAP protocol 
interface to communicate charging information between the bearer level system (i.e. the GGSN 
and the SGSN) and a CAMEL SCP (service control point) in order to remove the need for a 
separate charging interface and thus optimize the network architecture. Therefore it would have 
been obvious to one of ordinary skill in the art at the time of invention to modify the charging 
function of Mizell and Lundin to incorporate a CAMEL architecture as taught by Bos in order to 
optimize the network architecture. 

Regarding claim 40, the combination of Mizell, Lundin, and Bos teaches the serving node 
according to claim 39, wherein said accumulated volume is accumulated from classified and/or 
incompletely classified payload volumes, said accumulated volume count is being maintained as 
long as said PDP context is active (i.e. Lundin teaches that chain IDs are used to handle packet 
chains for which a service class in unable to be determined until the required number of packets 
have been received, therefore incompletely classified payloads; paragraph 0028). 
18. Claim 42 is rejected under 35 U.S.C. 103(a) as being unpatentable over Mizell in view of 
Lundin and further in view of US 2003/0120499 to MacLean et al. 

Regarding claim 42, Mizell teaches a gateway node for communicating within a system 
performing packet inspection and service classification, said system comprising a packet data 
network and a serving node, wherein IP data packets comprising payload data may be 
communicated for identification of a given predetermined service class out of a plurality of 
predetermined service classes within said system, said gateway node comprising: 
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means for receiving IP data packets in a continuous stream of IP data packets associated 
with a given PDP context (i.e. GGSN receives a data packet from an IP network, therefore a 
receiver on a network port; paragraph 0025, 0030, 0039); 

means for determining the service class of the payload data of said IP data packets 
associated with said PDP context payload (i.e. GGSN assigns a charging rate for each 
downloaded packet based on the packet contents (service class), therefore a processor for 
determining packet content type; paragraph 0030, 0041); 

means for storing an accumulated downlink volume count associated with said service 
class (i.e. GGSN keeps track of the volume of packets delivered to a SGSN through a PDP 
context and each packet's charging rate (service class), therefore a processor and memory for 
storing downlink volume; paragraph 0039, 0045); 

means for generating service class extension headers containing said service class for the 
downstream payload means for inserting said extension headers in packet data packet units (i.e. 
GGSN creates a GTP packet by encapsulating the downloaded packet, therefore a processor for 
inserting extension headers into packets; paragraph 0030, 0040); 

means for inserting said payload data in packet data packet units (i.e. GGSN creates a 
GTP packet by encapsulating the downloaded packet, therefore a processor for inserting payload 
data into packets; paragraph 0030, 0040); and 

means for transmitting said packet data units to said serving node (i.e. GGSN transfers 
the GTP packet to a SGSN, therefore a transmitter on a Gn interface; paragraph 0030, 0039). 

Mizell does not specifically teach that the continuous stream of data packets is an 
upstream nor: means for storing an accumulated uplink volume count associated with said 
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service class; and means for generating service class extension headers containing said service 
class for the upstream payload, said accumulated uplink volume count, and said accumulated 
downlink volume count; however, at the time the invention was made the preceding limitation 
was known in the art of communications. 

Lundin teaches a GPRS network wherein the GGSN adds traffic type indicators to the 
GTP header that are used to indicate the appropriate charging scheme to each packet; paragraph 
0028. Lundin teaches that one of the indicators may be the chain ID (volume count) to keep 
track of the number of packets received of a packet chain so that such chains can be properly 
processed; paragraph 0028. Packet chains arc packets for which a service class in unable to be 
determined until a required number of packets have been received, therefore incompletely 
classified pay loads; paragraph 0028. Thus it would be obvious to one skilled in the art that the 
combination of Mizell and Lundin teaches a processor for storing a chain ID value (aggregated 
volume count or information associated with incompletely classified payload data) and creating 
GTP headers with chain ID values. Therefore it would have been obvious to one of ordinary 
skill in the art at the time of invention to modify the GTP packets of Mizell to include chain ID 
as taught Lundin in order to handle packet chains. 

However, the combination of Mizell and Lundin does not specifically teach that the 
continuous stream of data packets is an upstream nor means for generating service class 
extension headers containing said service class for the upstream payload and said accumulated 
uplink volume count. 

MacLean teaches a context-based billing service in a GPRS network wherein both the 
uplink and downlink traffic are monitored and their volume is counted for context based billing; 
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paragraph 0025. Thus it would be obvious to one skilled in the art that the combination of 
MacLean with Mizell and Lundin teaches a receiver for receiving uplink traffic and a processor 
generating GTP extension headers for the uplink traffic. MacLean teaches that the GPRS 
network works to track the volume limits of prepaid customers and provide accurate billing for 
both uplink and downlink traffic. Therefore it would have been obvious to one of ordinary skill 
in the art at the time of invention to modify the GPRS network of Mizell to provide context- 
based billing for upstream traffic as taught MacLean in order to provide accurate billing for 
prepaid customers. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Bryan Pitt whose telephone number is (571) 270-7466. The 
examiner can normally be reached on Monday - Friday 8:30 am - 5:00 pm EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, George Eng can be reached on (571) 272-7495. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/George Eng/ 

Supervisory Patent Examiner, Art Unit 2617 



IB. P./ 

Examiner, Art Unit 2617 



